The present invention is related to workflow management systems, and in particular to a distributed computer system for workflow execution across a network infrastructure.
Workflow systems are essential to organizations that need to automate their business processes. Workflow systems allow organizations to specify, execute, and monitor their business processes in an efficient manner over enterprise-level networks. This has the net effect of improved throughput of processes, better utilization of organizational resources, and improved tracking of processes.
Many workflow systems are commercially available. Even though many workflow systems exist, interoperability across these systems is a technical problem. The systems are monolithic and proprietary, and workflows cannot extend beyond a single workflow system. To solve this problem, the Workflow Management coalition (WfMC), an industry-wide consortium of major workflow system vendors, has defined a standard workflow architecture, described in the document "The Workflow Reference Model" WFMC-TC-1003!. The model defines the major components of a workflow system and a set of interfaces between workflow system components. The major components it describes are a Process Definition or Builder Tool to capture business process logic in a high-level notation; a Workflow Server that acts as the nerve center of the workflow system; Workflow Clients that are used by users to view and interact with the contents of their worklists; Workflow Applications that are invoked by the workflow server to perform automated activities; and finally, Administration & Monitoring Tools used to administer the execution and monitor the status of work flowing through the workflow system using Audit Data.
The WfMC Reference Model also defines interfaces between these components. Interface 1 (builder-server interface) defines a common process definition format for the interchange of static process specifications between a Process Definition Tool and a Workflow Server WFMC-WG01-1000!. Interface 2 (client-server interface) defines an API that provides a complete range of interactions between a Workflow Client and a Workflow Server WFMC-TC-1009!. These include worklist interaction, query and control of workflow processes and their activities, and administrative functions. Interface 3 (application invocation interface) is not currently available, but is intended to describe how applications are invoked. Interface 4 (server-server interface) defines an API that describes the interactions between two Workflow Servers WFMC-TC-1012!. Interactions include initiation, query and control of workflow processes and their activities, and administrative functions. Finally, Interface 5 (monitor-server interface) defines audit data for administrating and monitoring a Workflow Server WFMC-TC-1015!.
The WfMC standard has significant weaknesses that make it unsuitable for a heterogeneous, distributed computing environment. Specifically, the design of current workflow systems based on the WfMC standard makes them inappropriate for workflow execution across wide area networks such as the Internet, where scalability, flexibility, and interoperability across heterogeneous systems and networks is the needed. The weaknesses of the WfMC architecture stem from the monolithic nature of the workflow server, which is responsible for process execution, management of the Staff Directory, binding of activities to participants and distribution of work items to appropriate workflow participants (performing role and group resolution as necessary), worklist management for all workflow participants who receive work items from the server, and application invocation. This leads to the following problems:
1. Participants cannot be shared by multiple workflow systems: Since participant worklists are hidden within the workflow server and are not externally addressable, processes are only able to send work items to worklists that reside in the same workflow server. Thus, in order for a participant to participate in multiple workflows running on heterogeneous servers, an identity and a worklist must be maintained separately inside each workflow server the client wishes to receive work from. In addition, the workflow client must now manage multiple client connections to each of these workflow servers in order to receive work. This overloads the client application with unnecessary functionality; whenever a participant wishes to participate in a large number of workflow applications from different servers, the participant has to connect to each server and explicitly `pull` work from it. Because of the complexity in the client, this architecture is not suitable for workflow participation using thin clients and lightweight, portable computing devices such as personal digital assistants. From a distributed design perspective, this is an unscalable solution.
2. Participants cannot work in disconnected mode: Even though work items are logically owned by the workflow participants, the WfMC architecture assigns the task of managing work items to the workflow server. Consequently, the participant interacts with a remotely located work item, and each interaction between the participant and an associated work item results in a remote access (usually a Remote Procedure Call (RPC)). While this design has potential benefits when work items must implement some server-side functionality, it imposes severe constraints on disconnected workflow participation, since the network must be constantly available for the participant to do any work. The WfMC standard also involves workflow servers in client-side application invocation, via the proposed Interface 3. For example, if a participant needs to invoke a local application such as a word processor as part of a work item, the workflow server that owns the work item must invoke the word processor on the participant's behalf on the participant's machine via the proposed Interface 3. The consequence of this intrusive approach is that participants can work only when directly connected to the workflow server-they cannot operate in a disconnected mode.
3. The execution of work is not transparent: The WfMC architecture makes clear distinctions between how the server assigns work items to human participants, how it invokes workflow scripts on other servers, and how it manages application invocation. For the first, it assigns work items to its internal worklist and expects the participant to explicitly `pull` the contents of the worklist using Interface 2. For the second, it explicitly `pushes` a request to another server using Interface 4. For the third, it performs a synchronous procedure call using Interface 3.
Treating work in three different ways leads the server to early judgments about the actual implementation of an activity. This leads to a loss of transparency, and makes it difficult for a work item at the level of the requesting server to be dynamically bound and implemented as a workflow by a participant domain at execution time.
U.S. Pat. No. 5,530,861 describes a task management method that allows humans to receive and manage tasks from different sources such as other individuals, process engines, and application agents. The task management scheme assumes that tasks are always performed by humans, and provides a standard way in which a human user can interact with tasks assigned to the user. The method does not deal with interoperability of workflow systems. It also does not deal with distributed workflow execution with respect to how tasks can be treated uniformly across application invocations, workflow script executions on heterogeneous systems, and human participants across a network. It does not deal with issues of disconnected operation, and recursive, dynamic workflow execution.